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Abstract.  The  software  development  process  for  many  space  observatories 
is  often  disjoint  and  inefficient  due  to  the  use  of  multiple  languages  during  the 
different  phases  of  mission  development.  Code  and  algorithms  that  are  often 
developed  using  an  interactive,  array  language  during  the  pathfinding  efforts  of 
Phase  A  are  often  rewritten  in  a  non-interactive,  compiled  language  for  use  in 
the  production  code  for  Phase  C.  This  approach  leads  to  inefficiency  in  both 
development  time  and  cost  and  can  introduce  errors  during  the  rewriting  pro¬ 
cess.  Python  is  one  programming  language  that  can  be  used  as  a  high-level, 
array  language  and  as  an  efficient,  production  language.  This  paper  shows  how 
Python  will  be  used  during  the  different  phases  of  development  of  the  Joint 
Milli-Arcsecond  Pathfinder  Survey  (JMAPS)  space  mission  with  an  emphasis 
on  code  and  algorithm  reuse  from  one  phase  to  the  next. 


1  Introduction 

The  Joint  Milli-Arcsecond  Pathfinder  Survey  (JMAPS)  is  a  micro-satellite  mission  in¬ 
tended  to  update  Hipparcos  astrometry.  With  its  single-aperture  19  cm  telescope, 
JMAPS  will  detect  not  only  the  stars  observed  by  Hipparcos  (V<  9  mag),  but  also 
extend  Hipparcos  level  milli-arcsccond  astrometry  to  14th  magnitude  stars.  Combining 
HI'  JMAPS  and  Hipparcos  data  will  provide  proper  motion  information  at  the  level  of  a 
few  tens  of  micro-arcseconds  per  year  for  stars  brighter  than  11  magnitude  in  the  V 
band.  Using  a  step-and-stare  mode  concept,  JMAPS  can  integrate  longer  for  specific 
fields  on  the  sky,  which  allows  the  JMAPS  star  catalog  to  tie  directly  to  version  2  of 
the  International  Celestial  Reference  Frame  (ICRF2)  by  observing  the  brightest  quasars 
m  the  optical.  The  JMAPS  program  is  in  the  design  and  development  stage,  with  an 
expected  launch  in  mid-2013. 


2  Motivation 

;.JMAPS  is  unusual  for  a  space  mission  in  that  the  timely  processing  of  the  data  has  a 
ii'.  significant  effect  on  the  overall  success  of  the  mission.  This  is  because  all  images  are 
-directly  related  during  the  global  block  adjustment  (see  Global  Solution  Simulator). 

order  to  minimize  global  systematic  errors,  the  results  of  the  ground  processing, 
jjpSpecifically  the  global  solution,  are  incorporated  into  the  planning  and  scheduling  system 
:;;Tn  a  periodic  basis.  This  creates  a  feedback  loop  among  the  Planning  &  Scheduling 
||J$stem,  the  Data  Management  System,  and  the  Data  Processing  System. 

Figure  1  shows  the  ground  system  data  flow  diagram.  The  core  of  the  system  is 
lni\lpr'SCd  the  Planning  &  Scheduling  System  (PSS)  and  Data  Management  System 
-MS).  These  two  systems  form  a  feedback  loop  in  order  to  optimize  the  long-term  (~  1 
’§$■)  observing  plan.  The  data  flow  begins  with  the  PSS,  where  the  weekly  schedules 
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Public  reporting  burden  for  the  collection  of  information  is  estimated  to  average  1  hour  per  response,  including  the  time  for  reviewing  instructions,  searching  existing  data  sources,  gathering  and 
maintaining  the  data  needed,  and  completing  and  reviewing  the  collection  of  information.  Send  comments  regarding  this  burden  estimate  or  any  other  aspect  of  this  collection  of  information, 
including  suggestions  for  reducing  this  burden,  to  Washington  Headquarters  Services,  Directorate  for  Information  Operations  and  Reports,  1215  Jefferson  Davis  Highway,  Suite  1204,  Arlington 
VA  22202-4302.  Respondents  should  be  aware  that  notwithstanding  any  other  provision  of  law,  no  person  shall  be  subject  to  a  penalty  for  failing  to  comply  with  a  collection  of  information  if  it 
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Figure  1.  Ground  System  Data  Flow  Diagram 


are  created.  The  schedules  are  sent  to  the  Mission  Operations  Center  for  execution  and 
also  recorded  in  the  DMS.  When  the  science  data  are  ingested  into  the  DMS,  they  are 
checked  against  the  schedule  for  discrepancies,  which,  if  necessary,  are  included  in  the 
next  long-term  plan  or  weekly  schedule. 


3  Approach 


3.1  Code  Reuse:  From  Pathfinding  To  Operations 

As  with  all  space  missions,  resource  and  schedule  constraints  place  a  strong  emphasis 
on  productivity.  Reusing  software  is  one  way  to  improve  productivity  during  mission 
design  and  development.  In  order  to  achieve  this,  a  conducive  environment  for  software 
development  must  be  in  place  during  the  earliest  stages  of  the  mission.  This  is  when 
most  software  development  is  being  done  by  scientists  and  engineers,  who  neither  know 
nor  care  about  software  development  methodology.  However,  much  of  the  software 
that  they  develop  during  this  mission  phase  can  be  reused  in  the  operational  system. 
Therefore,  there  is  a  strong  desire  to  have  a  programming  language  and  development 
environment  that  is  easy  to  use  during  the  design  phase  and  that  is  also  efficient  enough 
for  the  operational  phase. 

One  aspect  of  a  conducive  development  environment  is  a  high  level  programming 
language.  This  language  should  provide  an  easy  interface  to  multi-dimensional  arrays, 
so  that  scientists  and  engineers  can  easily  develop  code  for  their  analysis.  This  lan¬ 
guage  should  also  be  object-oriented,  so  that  the  shared  libraries  and  utilities  are  well 
defined,  robust,  and  easy  to  use.  If  properly  designed,  tested,  and  documented,  most 
of  the  shared  libraries  and  utilities  can  be  reused  in  the  operational  code.  The  Python 
programming  language  meets  these  criteria.  In  addition,  several  informal  studies  show 
increased  productively  of  several  hundred  percent  compared  to  compiled  languages  (see 
e.g.,  the  comparison  to  Java'by  Ferg,  S.  2004). 
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3.2  Object  Modeling  and  Shared  Code 

The  JMAPS  program  has  made  an  effort  early  in  the  mission  to  develop  code  using  Agile 
programming  methodology  (see  e.g.,  Beck  et  al.  2001).  An  important  aspect  of  this  ap¬ 
proach  is  to  begin  object  modeling  as  soon  as  possible  by  identifying  and  defining  class 
interfaces  that  are  common  to  the  various  pathfinding  projects.  Currently,  the  three 
pathiinding  projects  are  progressing  somewhat  independently,  because  they  have  differ¬ 
ent  near-term  objectives.  In  the  future,  the  goal  is  to  begin  integrating  these  projects 
into  a  larger  system  in  order  to  perform  more  accurate  simulations  of  the  mission.  In 
particular,  there  is  a  close  association  between  the  Planning  &  Scheduling  Simulator 
and  the  Global  Solution  Simulator.  This  integration  is  most  easily  accomplished  if  each 
project  is  using  a  common  set  of  classes.  Examples  of  the  common  classes  that  have  been 
identified  to  date  are:  Catalog  (DBCatalog,  FileCatalog),  Satellite,  Bus,  Instrument, 
Telescope,  Detector,  and  Scan  (MeridianScan,  LongitudinalScan,  etc.). 


4  Pathfinding 

4.1  Focal  Plane  Simulator 

The  JMAPS  Focal  Plane  Simulator  (Jsim)  is  a  Python  application  that  is  currently 
being  developed  to  support  requirements  analysis  associated  with  the  focal  plane  array. 
Known  characteristics  of  the  detectors  are  included  in  order  to  understand  their  effect 
on  the  astrometric  and  photometric  sensitivity  of  the  mission.  Read  and  photon  noise, 
variable  point-spread  functions,  satellite  jitter,  and  variations  of  instrument  parameters 
such  as  focal  length  and  orientation  have  been  tested. 


4.2  Planning  and  Scheduling  Simulator 

■:  The  JMAPS  observing  concept  differs  from  other  astrometric  satellites  by  using  a  step- 
‘  and-stare  observing  mode,  whereas  Hipparcos  and  GAIA  are  scanning  missions.  The 
■greater  flexibility  of  this  mode  has  its  costs  in  that  ~  500000  images  must  be  scheduled 
over  an  extended  period  (~  1  year).  The  Planning  &  Scheduling  Simulator  is  an  effort 
to  identify  the  best  observing  methods  and  to  evaluate  various  planning  and  scheduling 
applications  (both  free  and  commercial). 


:  4.3  Global  Solution  Simulator 

The  JMAPS  astrometric  telescope  has  a  field  of  view  of  1.56  square  degrees,  so  > 
'  26000  images  are  required  to  cover  the  entire  sky  once.  JMAPS  will  observe  the  entire 
:  sky  at  least  72  times  during  the  3  year  mission.  For  precise  astrometry,  >  500000 
reference  stars  uniformly  covering  the  sky  will  be  used  to  calculate  the  stellar  and 
j-cimage  parameters,  i.e.,  the  positions,  proper  motions,  and  parallaxes  of  the  reference 
df  Stars  and  the  position,  orientation,  and  scale  of  the  images.  This  involves  solving  for 
fc  about  25  million  parameters  (~  5  million  for  stars  and  ~  20  million  for  images).  One 
aPproach  to  calculating  these  parameters  is  called  Global  Block  Adjustment  (GBA).  All 
■  parameters  are  calculated  simultaneously  by  solving  a  large  sparse  linear  system, 
i  There  are  several  methods  for  solving  this  type  of  sparse  system  using  direct  and 
'iterative  (Krylov)  solvers.  The  Global  Solution  Simulator  is  one  pathfinding  effort  to 
investigate  the  best  approach  to  solving  this  problem.  Figure  2  is  a  plot  of  a  simulation 
showing  the  variation  of  the  residual  error  on  number  of  images  and  the  reference  star 
Positions.  During  operations,  the  results  of  the  Global  Solution  will  be  used  for  long- 
Arm  (~  1  year)  planning  and  weekly  scheduling  of  the  satellite. 


Plates:  242  Star  density:  10  angle  max  resid.:  8.2e-01 
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Figure  2.  A  residual  map  from  a  global  solution  simulation.  Squares  show 
outline  of  images  on  the  sky  and  small  circles  are  positions  of  reference  stars. 


5  Summary 

For  this  software  development  approach  to  be  fully  successful,  it  requires  buy-in  by  sci 
entists  and  engineers  early  in  the  program,  since  they  are  partly  laying  the  groundwork 
for  later  software  development.  The  concepts  of  object-oriented  design  and  development 
often  take  time  to  grasp  fully.  In  addition,  classes  that  have  an  intuitive  interface  and 
are  fully  functional,  take  time  to  develop,  test,  and  document  (although  the  long-term 
return  usually  outweighs  the  initial  investment).  ■* 

For  the  USNO  ground  segment  portion  of  the  JMAPS  program,  we  obviously  be¬ 
lieve  that  the  approach  to  software  development  outlined  here  is  preferred,  since  a -large 
portion  of  the  software  development  must  be  done  to  support  the  extensive  simulations 
of  the  instrument  and  bus  to  assure  mission  success.  It  is  therefore  reasonable  to  reuse 
this  code  in  the  operational  system  to  increase  productivity  and  minimize  risk,  since  the 
core  components  of  the  operational  system  must  be  fully  functional  or  fully  integrated 
into  the  mission  by  launch. 
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